新工具簡介

在上一篇文章中分享了舊的維護模式工具的運作機制，以及該工具遇到的問題。

這篇文章將分享筆者重新設計後的維護模式工具，請見下圖：

上圖呈現了同一套架構在不同階段中的變化。分別是一般模式，維護模式和開啟白名單後的狀態。

首先，在一般模式下，使用者一樣透過 Route 53 的 DNS Routing 規則來獲得並存取 ALB 的 endpoint ，並藉此再存取後面的 EC2 。如果要進入維護模式的話，則在ALB外面加上一層 AWS 的另一個防火牆服務， Web Application Firewall(WAF) 。透過 WAF 的規則來管理可以進入的對象。維護模式下一開始會先關閉所有存取權限，等到需要開啟白名單的時候，再透過修改 WAF rule 來允許指定的對象存取 ALB 。

這整個切換的過程，仍然是透過一個 Python Script 來完成的。

新工具的特色

這個設計相較於原本的架構，有至少以下 3 個優點：

• 更簡單的架構
• 避免更改到原本架構的設定
• 在程式與白名單管理上更加簡單和方便

針對第一點，也就是相對於舊工具的缺點，我們可以不用再每一個單一服務都維護 2 套架構，而這也包含 DNS Record 中的設定。雖然只是短短一句話，但這其實是最重要的優點，因為架構的節省也代表成本的節省。

針對第二點，在 ALB 外面再包一層的做法，可以避免修改到 ALB 本身的設定，能夠一定程度上避開一些預期之外，比如因為 Infrastructure as Code(IaC) 而導致的問題。雖然由於在 ALB 上面包上 WAF ，仍然會需要加上一個 ALB 與 WAF 的串接設定，但至少比起直接修改 ALB rule 還要單純許多。

針對第三點，前一篇文章中提到，舊工具在白名單設定上極為複雜與混亂。因為 WAF 本身沒有那麼明確的「一個 rule 對 5 個 IP 」的限制，因此這在架構和程式撰寫上可以說是幫了一個大忙。不只能夠寫出更優雅且可讀性更高的程式，在架構上也相點容易維護非常多。

講完優點，這邊其實也有另一個不能忽視的成本問題。因為 WAF 本身其實並不便宜，在大流量的情況下可能會形成一筆可觀的費用。所幸我們只在維護模式時使用，除了並非長期使用 WAF 之外(用完就會刪掉資源)，維護模式的當下也不會有什麼使用者流量。因此最後計算出的成本是完全可以被接受的。

事實上，這裡我們不能否認可能會有更好的解決方法。因為該解決方案，其實預設了我們的服務一開始是沒有使用 WAF 的。如果我們未來會需要使用 WAF 的話，那很顯然就會與這個維護模式的工具有所衝突。畢竟 WAF 一開始的設計應該是為了做防火牆，而不是用來做維護模式的工具。

分享完改善後的新工具，下一篇文章將會分享在整個設計的過程中遇到的各種問題與挑戰。